If this exception is thrown, it may not be clear to the caller what the invalid rank was - can you think how to make this more clear?

Did you have any thoughts here?

throw new Error(Invalid card rank: "${rank}"from card "${card}" ); would be more clear to specify what card was wrong.

This works, but: either of these lines of code could handle the value 10 - why did you decide to handle it in the K/Q/J case rather than the number case?

By grouping "10" with "K", "Q", and "J", you make the intention clear:

"These are all cards that are worth 10 points, no matter what."

It also avoids need of extra range check (num === 10) in the number parsing block, which could make the logic more complex.

I understand your thoughts on the grouping, but in terms of the code, I think a different grouping may make sense here.

"These are all cards whose value is exactly what's written" vs "These are cards we need to treat specially" feels like a more important difference to me than "These are cards worth 10 points".

And in terms of logic complexity, you already have an upper bound in your range check. So I think:

if (["K", "Q", "J"].includes(rank)) return 10;

// ...

if (num >= 2 && num <= 10) return num;

is actually simpler than

if (["K", "Q", "J", "10"].includes(rank)) return 10;

// ...

if (num >= 2 && num <= 9) return num;

Including "10" in the array involves writing more code. Either way you need an upper bound on the num case, so the difference is really just whether you have an extra element in the array.

These are correct expectations, but they're not tests written in Jest - can you try to write actual tests for these cases?

Why did you change this line? What was broken about what it did before?

expect(repeat(str, count)).toEqual("hellohellohello");
Calls the repeat() function directly inside the test.
It’s like saying: “Call the function now with str and count, and I expect it to return "hellohellohello".”

before it was saying "I expect the value stored in repeatedStr to equal "hellohellohello"

It might not be broken but i find it unnecessary step

I think is makes sense but you probably want to delete the repeatedStr variable if you're going to do this.
Right now is slightly the worst of both situations - you have the extra variable but you're not using it which is confusing. I agree that calling repeat directly in the assertion is fine and clear!